NLB 経由で手元の Windows 11 からプライベートサブネットの EC2(RHEL9)に WinSCP でファイル送受信してみた

NLB 経由で手元の Windows 11 からプライベートサブネットの EC2(RHEL9)に WinSCP でファイル送受信してみた

NLB 経由で、手元の Windows 11 からプライベートサブネットの EC2(RHEL9)に WinSCP でファイル送受信してみました。NLB はスティッキーセッション未サポート、350 秒以上無活動の接続を自動的に切断するという仕様があるため、システム要件を加味し慎重に選定してください。
Clock Icon2023.11.05

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

コーヒーが好きな emi です。

今回は NLB 経由で、手元の Windows 11 からプライベートサブネットの EC2(RHEL9)に WinSCP でファイル送受信してみました。

ファイル送受信や SSH 接続で NLB を経由させる場合は注意点があります。
手順を先に見たい方は 検証:WinSCP でのファイル送受信 からご覧ください。

プライベートサブネットの EC2(RHEL9)にオンプレミスサーバーや手元の開発端末からファイルを共有したい

プライベートサブネットの EC2(RHEL9)にオンプレミスサーバーや手元の開発端末からファイルを共有したいケースがあります。
よく考えられるのは「踏み台サーバー経由でファイル共有する」「Transfer family で S3 バケットにデータを配置し、S3 バケット経由でファイル共有する」などのパターンです。

プライベートサブネットの EC2 にオンプレミスサーバーや手元の開発端末からファイルを共有したい場合は他にも以下のように様々な方法が考えられます。

項番 構成案 メリット デメリット
1 EC2 をパブリックサブネットに配置 ・クライアント側はこれまでと同じ操作で対応できる
・安価で導入が容易
・インターネットからアクセス可能になってしまう
・例えば操作ミスでセキュリテイグループを許可してしまうと外部からアクセスできてしまう
2 踏み台用 EC2 を構築し SSH ポートフォワード ・安価で導入が容易 ・踏み台自体の運用・セキュリティを考慮する必要がある
・ポートフォワードの設定をする必要がある
3 NLB 経由でのデータ送受信 ・クライアント側はこれまでと同じ操作で対応できる
・マネージドサービスなので運用が楽でセキュリテイも担保できる
・NLB と Elastic IP の維持費用がかかる
・スティッキーセッション未サポートのため、NLB のターゲットグループに複数のインスタンスが含まれる場合、同一クライアントから複数の SSH 接続リクエストが異なるターゲットにルーティングされ不安定になる可能性がある
・NLB は 350 秒以上無活動の接続を自動的に切断する
4 Transfer family で S3 バケット経由のデータ送受信 ・マネージドサービスなので運用が楽でセキュリテイも担保できる ・データの送受信経路が変わるためアプリ側の変更や検証が必要
5 VPN / Direct Connect ・閉域通信が可能 ・導入に時間がかかる
・回線敷設手配や NW 機器の設定が必要
6 Systems Manager を利用した WinSCP や SCP コマンドの利用 ・AWS リソースを追加構築せず利用可能 ・ クライアント側で設定しないといけないことが多いためクライアント台数が増えると運用が大変
・クライアント側に IAM クレデンシャルを設定する必要があり、クレデンシャルの発行や管理の手間・危険性がある
・セッションを毎回張る必要があり、定期データ送受信のためにはスクリプトを作成するなどの検証が必要
7 EC2 Instance Connect エンドポイントを利用した WinSCP や SCP コマンドの利用 ・EC2 Instance Connect エンドポイントの追加構築により利用可能
・EC2 Instance Connect エンドポイントは無料
・ クライアント側で設定しないといけないことが多いためクライアント台数が増えると運用が大変
・クライアント側に IAM クレデンシャルを設定する必要があり、クレデンシャルの発行や管理の手間・危険性がある
・セッションを毎回張る必要があり、定期データ送受信のためにはスクリプトを作成するなどの検証が必要
8 AWS マネジメントコンソールで S3 バケットにファイルをアップロードし、S3 バケットからファイルを取得する ・安価で導入が容易 ・利用者ごとに AWS マネジメントコンソールにアクセスできる IAM ユーザーを発行する必要がある
・AWS マネジメントコンソールを利用して手動で作業するため自動化が難しい

しかし、今回は「EC2 インスタンスを AWS Auto Scaling でスケーリングせず、1 台のみ」、「データを EC2 内部に保持している」、「ファイル共有したい周辺サーバーや開発端末が多く、SSM ポートフォワードや EC2 Instance Connect エンドポイントだと周辺サーバーや開発端末の設定が大変」等の前提があったため、NLB 経由での SCP ファイル送受信を試してみました。

Systems Manager セッションマネージャーを使いたい場合は以下のブログをご参照ください。

NLB のおさらい

Network Load Balancer(NLB)は、OSI 参照モデルの第 4 層で機能します。 毎秒数百万のリクエストを処理でき、以下のようなケースで利用できます。

  • 高スループット・低レイテンシーの通信が必要な場合
  • Elastic IP アドレスが必要な場合(IP を固定したい場合)
  • WebSocket や IoT デバイスなど、長時間の TCP 接続を維持する必要がある場合

注意点

SSH や SFTP は通常長期間の接続を必要とし、その接続は特定のクライアントとサーバーの間で維持されます。ロードバランサーを介すると接続は複数のサーバー間で分散され、それにより接続が不安定になる可能性があります。

本記事の検証のように SSH や SFTP の接続をロードバランサーを介して行うことも可能ですが、以下の点に注意してください。

  • スティッキーセッションは未サポート
    • NLB はスティッキーセッション(同一クライアントからの複数のリクエストを同じターゲットにルーティングする機能)をサポートしていません。NLB のターゲットグループに複数のインスタンスが含まれる場合、同一クライアントから複数の SSH 接続リクエストが異なるターゲットにルーティングされる可能性があります。
    • 本記事の構成のように、NLB のターゲットグループに含まれる EC2 インスタンスが 1 台のみの場合、全てのリクエストは同一のインスタンスにルーティングされるため、接続の整合性は保たれます。
  • 接続タイムアウト
    • NLB は 350 秒以上無活動の接続を自動的に切断します。SSH や SFTP の接続が長期間開放される場合、接続の切断を引き起こす可能性があります。
    • SSH や SFTP の通信が短時間で完了し、ターゲットのインスタンスが 1 台のみである場合、この設定による影響は抑えられます。
    • 参考:接続のアイドルタイムアウト


検証:WinSCP でのファイル送受信

今回の検証構成図

以下のような構成で検証します。NLB のターゲットグループには EC2(RHEL9)が 1 台だけ含まれるようにします。

事前に VPC と EC2(RHEL9)を作成しておいてください。手元の Windows 11 端末には WinSCP をインストールしておいてください。

NLB のターゲットグループの作成

NLB を作成する前に、ターゲットグループを作成しておきます。

EC2 コンソール画面より、[ターゲットグループ] - [ターゲットグループの作成] をクリックします。

  • ターゲットタイプの選択:インスタンス
  • ターゲットグループ名:任意の名前(今回は「nlb-sftp-test-tg」としました)
  • プロトコルポート:TCP、22
  • IP アドレスタイプ:IPv4
  • VPC:EC2 インスタンスが作成済みの VPC を選択

  • ヘルスチェックプロトコル:TCP

その他はデフォルト値で「次へ」をクリックします。

「ターゲットを登録」画面で、作成済みの EC2(RHEL9)にチェックを入れ、「保留中として以下を含める」をクリックします。すると、下部の「ターゲットを確認」欄に選択した EC2 が表示されます。
「ターゲットグループの作成」をクリックします。

ターゲットグループができました。

NLB の作成

NLB と、NLB に割り当てるセキュリテイグループを作成します。

EC2 コンソール画面より、[ロードバランサー] - [ロードバランサーの作成] をクリックします。
Network Load Balancer の項目で「作成」をクリックします。

  • ロードバランサー名:任意の名前を入力(今回は「nlb-sftp-test」としました)
  • スキーム:インターネット向け
  • IP アドレスタイプ:IPv4
  • ネットワークマッピング:作成済みの VPC を選択
  • マッピング
    • ターゲットとなる EC2 インスタンスを作成した AZ と同じ AZ にチェックする
      • サブネット:パブリックサブネットを選択
      • IPv4 アドレス:今回は「Elastic IP アドレスの使用」を選択
        • IP アドレスを固定したいときは Elastic IP アドレスを選択します。
        • DNS 名でしかアクセスしない、もしくは IP アドレスが変更されても問題ない場合は「AWSによって割り当て済み」を選択します。

次は NLB に割り当てるセキュリティグループを設定します。
「新しいセキュリティグループを作成」のリンクをクリックすると、ブラウザの別タブでセキュリティグループの作成画面が開きます。

  • セキュリティグループ名:任意のセキュリティグループ名(「test-sg-nlb」など)
  • 説明:任意の説明文を入力(日本語は使えない)
  • VPC:ターゲットとなる EC2 インスタンスを作成した VPC を選択
  • インバウンドルール
    • タイプ:SSH
    • ソース:任意のソース IP(今回は「マイ IP」を選択し、自身の手元の Windows 11 端末がインターネットにアクセスする際のパブリック IP を指定)

インバウンドルールの説明やタグは任意で指定してください。
最後に「セキュリティグループの作成」をクリックします。

セキュリテイグループができました。

それでは、NLB を作成していたブラウザタブに戻ります。
更新ボタンを押すと今作成したセキュリテイグループがプルダウンで選択できるようになっていますので、今作成したセキュリテイグループを選択します。

  • リスナー
    • プロトコル:TCP
    • ポート:22
    • デフォルトアクション:先程作成したターゲットグループを選択(今回は「nlb-sftp-test-tg」になります)

その他の項目はデフォルトのままで、「ロードバランサーの作成」をクリックします。

ロードバランサーができました。「ロードバランサーを表示」をクリックします。

作成した NLB の詳細画面が開きます。EC2 インスタンスに接続する際に使用するため、DNS 名をコピーしておいてください。

EC2 インスタンスのセキュリティグループの編集

次は EC2 インスタンスのセキュリティグループを編集し、NLB からの SSH 接続を許可するインバウンドルールを追加します。

EC2 に付与されたセキュリテイグループの詳細画面を開きます。「インバウンドルール」タブで「インバウンドルールを編集」をクリックします。
(画像では既に 1 行インバウンドルールが存在していますが、本検証には影響がない部分なので無視してください)

  • タイプ:SSH
  • ソース:カスタムを選択し、NLB に紐づけたセキュリテイグループを選択(「sg」と入力すると候補で出てきます)

「説明」は任意で入力し、「ルールを保存」をクリックします。

NLB からの SSH 接続を許可するインバウンドルールを追加できました。

ここまでで、NLB にはマイ IP から SSH のインバウンド通信を許可、EC2 には NLB のセキュリティグループから SSH のインバウンド通信を許可する設定になっています。

ターゲットグループのヘルスステータス確認

セキュリテイグループによる適切な通信許可設定をおこなったので、ターゲットグループのヘルスステータスは「Healthy」になりました。
ステータスが「異常」になっている場合は、

  • EC2 インスタンスが起動していて sshd プロセスが起動しているか
  • セキュリテイグループの設定が正しく行われているか

を確認してください。

キーペアの作成と設定

EC2 インスタンスにキーペアを設定していない場合はキーペアを設定してください。
キーペアを後から EC2 インスタンスに設定する場合は以下ブログの

を参照ください。

なお、RHEL 9.0 では SHA-1 が非推奨になったことにより、キーペアのタイプが「RSA」だと鍵認証に失敗することがある模様です。
本検証ではキーペアのタイプ「RSA」ででうまく行きましたが、SSH 接続をおこなう場合、キーペアのタイプは「ED25519」を選択してください。

WinSCP での接続

WinSCP で EC2 インスタンスに接続します。
WinSCP を開き、以下のように入力します。

  • 転送プロトコル:SFTP
  • ホスト名:コピーしておいた NLB の DNS 名、または NLB に付与した Elastic IP アドレス
  • ポート番号:22
  • ユーザー名:ec2-user(キーペアを登録したユーザー)

入力できたら「設定」をクリックします。

[SSH] - [認証] の「秘密鍵」で、キーペア(.ppk 形式)を保存している手元の Windows 11 端末のパスを入力します。
入力できたら「OK」をクリックします。

「ログイン」をクリックします。

初めて接続する際は、以下のように警告が出ます。このまま「はい」で進めます。

EC2 インスタンスに NLB 経由で接続できました。

WinSCP でのファイル送受信

手元の Windows 11 端末のエクスプローラーから、WinSCP にテストファイルをドラッグ&ドロップします。

テストファイルを EC2 上にアップロードできました。

WinSCP 上で見えている EC2(RHEL9)上のファイルを、ドラッグ&ドロップで手元の Windows 11 端末にコピーすることもできます。

終わりに

今回は「EC2 インスタンスを AWS Auto Scaling でスケーリングせず、1 台のみ」、「データを EC2 内部に保持している」、「ファイル共有したい周辺サーバーや開発端末が多く、SSM ポートフォワードや EC2 Instance Connect エンドポイントだと周辺サーバーや開発端末の設定が大変」等の前提があったため NLB 経由での SCP ファイル送受信を試してみました。
どなたかのお役に立てば幸いです。

参考

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.